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1, INTRODUCTION 


Intelligent Transportation Systems (ITS) are applications of advanced technology in the field of 
transportation, with the goals of increasing operational efficiency and capacity, improving safety, 
reducing environmental costs, and enhancing personal mobility. Successful ITS deployment 
requires an approach to planning, implementation, and operations that emphasizes collaboration 
between relevant entities and compatibility of individual systems. At the core of this process is an 
architecture that guides the coordination and integration of individual ITS deployment projects. This 
ITS architecture is a framework that defines the component systems and their interconnections, and 
that provides a tool for facilitating institutional relationships within a region. 


The Commonwealth of Massachusetts, through the Executive Office of Transportation (EOT), has 
undertaken the development of a Regional Intelligent Transportation Systems Architecture for 
Metropolitan Boston. For the purposes of this study, Metropolitan Boston was defined as the area 
generally within I|-495, Boston’s outer circumferential highway. The Office of Transportation 
Planning (OTP) has led a project team consisting of IBI Group in association with ConSysTec 
Corporation and Rizzo Associates. The consultant team also included an advisory panel consisting 
of James McGrail, Esq. of Nora Burke and Co., Paula Okunieff of Systems & Solutions, Inc., and 
Dr. Joseph Sussman of the Massachusetts Institute of Technology. 


Key transportation agencies and other stakeholders in the region provided extensive input in the 
process, with many serving on a Guidance Committee. Their involvement included participating in 
meetings and workshops and reviewing project deliverables. Out of this process, with the help of 
these stakeholders, came an architecture that represents a vision of an integrated transportation 
system for the Metropolitan Boston region and the interagency relationships needed to support it. 


1.1 Architecture Development Process 


This Implementation Plan is one of the final steps in the regional ITS architecture development 
process, as illustrated in Exhibit 1-1. This section provides a review of this process. 
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Exhibit 1-1: Architecture Development Process 


The first step of this process was the Needs Analysis, which identifies the ITS-related projects and 
needs of the operating and planning agencies in the region. This analysis served as the basis for 
the development of the functional requirements of the ITS Architecture and its component systems, 
developed in the following step. This approach ensured that the systems and technologies 
recommended for implementation, as well as the architecture that provides a framework for these 
systems, were consistent with the needs and goals of the region. Documentation from the region, 
including Regional Transportation Plans (RTPs) and Transportation Improvement Programs (TIPs), 
was reviewed as part of the needs analysis. Further information was obtained at a meeting of the 
Guidance Committee and through follow-up meetings with individual agencies. 
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The next step in the process was the development of the ITS Architecture, which defines the 
existing and planned component systems and the interfaces among them. As with the needs 
analysis, stakeholder involvement was critical to this step of the process. An initial draft of the 
architecture was developed from an inventory of ITS elements identified in the needs analysis and 
from stakeholder input at an architecture development workshop. Refinements to the architecture 
were made following stakeholder review, including a series of follow-up review meetings with 
various groups of stakeholders. Final refinements to the architecture were made once the 
architecture process was completed, allowing the architecture to reflect all of the comments 
received. 


The next two steps resulted in documents derived directly from the ITS architecture. The first was 
the development of the Operational Concept, which addresses the institutional relationships that 
must be established in order to address the interagency interfaces defined in the architecture. The 
purpose of the Operational Concept is to define the roles and responsibilities of the stakeholders in 
the operation of the component systems of the architecture. The Operational Concept details 
requirements for each of the interagency interfaces in the architecture. These requirements 
address the information to be exchanged and the roles of the interfacing agencies. The Operational 
Concept also addresses the need for operational agreements among agencies that share 
interfaces. 


The final piece of the architecture development process was the development of the 
Implementation Plan, which provides a strategy for achieving the integrated transportation system 
envisioned by the architecture. The Implementation Plan addresses the planned components of the 
architecture, identifying a series of initiatives that can be undertaken to implement these 
components. Also included in this step was the development of a plan for maintaining the 
architecture and ensuring consistency between the architecture and projects with ITS components. 


1.2 Development of the Implementation Plan 


This document presents a strategy for implementing the systems defined in the Regional ITS 
Architecture for Metropolitan Boston. This strategy is developed directly from preceding steps in 
the architecture development process, as illustrated in Exhibit 1-2. 
























































Needs ITS Implementation 
Analysis Architecture Plan 
| a . oi ‘ Pe ON 
Existing Existing | 
> Program Areas 
ITS Inventor Elements 
= Z ed 
Regional Needs Eee | Initiatives 
Elements 
a <—_,—_/ 
(— > 
> Prioritization 
a, 











Exhibit 1-2: Implementation Plan Development Process 


The architecture identifies a large number of ITS elements for the region, classified as either 
“existing” or “planned.” Elements classified as “existing” are those that are already implemented or 
those that are far enough along in the design stage that the interfaces are already determined. 
These elements, identified in the ITS inventory from the needs analysis, therefore are not 
addressed in the Implementation Plan. 
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The elements that must be considered in the Implementation Plan are those classified as “planned,” 
i.e. those that have not yet been designed or implemented but that are envisioned to be 
implemented within a ten-year horizon. These elements were identified based on the outcome of 
the Needs Analysis and the input from stakeholders during the architecture workshop. In addition 
to the planned ITS elements, there are planned interfaces that must be considered. For example, a 
planned interface between two existing control centers must be included in the Implementation 
Plan, even though it is not associated with a planned element in the inventory. 


In developing the Implementation Plan, the planned elements identified are considered both by 
function and by stakeholder. Considered functionally, the planned elements are grouped into 
program areas that encompass elements that address a specific functional need. Each program 
area represents a general area for investment identified through the architecture development 
process. 


Within each of the program areas, a series of initiatives is defined, representing a means of 
implementing the elements with that program area. Each initiative may encompass a number of 
planned elements that are recommended for simultaneous implementation. Although a single 
stakeholder will lead some initiatives, many initiatives will require the participation of two or more 
agencies. 


As an example, consider the interface between a MassHighway District Office and MassHighway 
maintenance vehicles. The information flows between these entities include maintenance and 
construction dispatch data, location data, and status data. These interfaces can be grouped under 
a single initiative, namely “MassHighway CAD/AVL,” as each of these information flows would likely 
be implemented as part of a single CAD/AVL deployment. These interfaces would also fall under a 
broader program area, namely “CAD/AVL for Maintenance Vehicles,” that would also include 
CAD/AVL projects for maintenance vehicles at other agencies, such as local cities and towns. As 
the example illustrates, the program area defines the functional area recommended for 
implementation, namely CAD/AVL for Maintenance and Construction, while the initiative defines a 
specific deployment. 


Finally, the Implementation Plan also considers prioritization of the identified initiatives, identifying 
candidates for near-term and longer-term implementation. This prioritization is based on the needs 
analysis, the input received from the stakeholders throughout the architecture development 
process, and interdependencies among the initiatives. 


Through this process, a comprehensive list of program areas and initiatives has been developed 
that encompasses all of the planned elements from the architecture. The remainder of this 
document is organized as follows: 


= Section 0 presents the program areas and initiatives of the Implementation Plan, grouped by 
function. 


"Section 3 presents the strategy for implementation, considering the prioritization of the 
initiatives identified in Section 0. 
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2. PROGRAM AREAS AND INITIATIVES 


This section presents a set of program areas, along with a recommended set of initiatives to be 
implemented within each program area. Each program area represents a general area of 
investment that is needed for implementation of the architecture. 


Presented within each program area is a series of initiatives that provide a method of implementing 
that portion of the architecture. Some of the initiatives are currently planned initiatives that were 
identified in the development of the architecture. The others are recommendations for initiatives that 
address the needs identified in the development process. The initiatives defined in this section are 
not the only means by which the architecture can be implemented, however. Instead, this plan 
provides one method of grouping the planned elements of the architecture into initiatives that 
together address the needs and planned components from the architecture. 


Each of the initiatives presented indicates the stakeholders that are involved. While many initiatives 
involve only a single stakeholder, in some cases an initiative requires participation from multiple 
agencies. Furthermore, some initiatives are listed for a collective group of stakeholders, such as 
Regional Transit Authorities. These initiatives are not necessarily meant to cover multiple agencies 
or to consist of a one-time deployment. Instead, each represents an initiative that can be 
implemented multiple times within the region and on any scale, from single-agency to multi-agency 
to region-wide implementation. 


The subsections below present the program areas and initiatives arranged by function, based on 
the service areas or high-level grouping of market packages defined in the National ITS 
Architecture. The program areas are presented under the following functional groupings: 


" Traffic Management 
o Roadway Management 
ao Parking Management 
=" Maintenance and Construction Management 
= Public Transportation 
o Transit Management 
«Electronic Fare Payment 
« Traveler Information 
= Commercial Vehicle Operations 
=» Emergency Management 
« Archived Data Management 


In addition, there are a number of program areas that cut across multiple functions and thus do not 
fall under a single classification. These multi-function programs are presented in Section 2.1. 


2.1 Multi-Function Program Areas 


Presented in this section are the program areas that cut across multiple functional areas, and 
therefore cannot be classified under a single function. These program areas consist of those that 
provide or support more than one function, such as both traffic management and transit 
management. 


2.1.1 INFORMATION SHARING (EVENTS) 
This program area covers the sharing of event information among the various operations centers in 


the region. This addresses the center-to-center interfaces for event data that are shown in the 
architecture between these elements, including both roadway and transit control centers. The 
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functional areas covered by this program area are Traffic Management, Maintenance and 
Construction Management, Public Transportation, and Traveler Information. 


The interfaces covered by this program area can be implemented through an event reporting 
system, as recommended through the architecture development process. The following initiative 
addresses this program area. 


Event Reporting System 


This initiative will develop an event reporting system for exchanging of event information. This 
system, envisioned to be an expansion of the pilot system for Pioneer Valley developed by 
MassHighway, is an Internet-based tool that serves as a centralized repository for information on 
events affecting the transportation network. Participating agencies can enter information about 
events within their jurisdiction and can view information entered by other agencies, thus 
providing a central system for information exchange. The participating agencies are the 
following: 


=" Roadway Agencies: 
«© Boston Transportation Department (BTD) 
a City of Brockton 
2 Local Cities/Towns 
« Massachusetts Highway Department (MassHighway) 
co Massachusetts Turnpike Authority / Central Artery/Tunnel (MassPike / CA/T) 
«Massachusetts Port Authority (Massport) 
2 Metropolitan District Commission (MDC) 


«Transit Agencies: 
«© Brockton Area Transit (BAT) 
a2 Cape Ann Transportation Authority (CATA) 
«Greater Attleboro-Taunton Regional Transit Authority (GATRA) 
a Lowell Regional Transit Authority (LRTA) 
« Massachusetts Bay Transportation Authority (MBTA) 
a Merrimack Valley Regional Transit Authority (MVRTA) 
2 Local Cities/Towns 
o Other Transit Providers 


» Emergency Management Agencies: 
« Boston Emergency Management Agency (BEMA) 
2 Local City/Town Public Safety 
o  MBTA Police 
o Massachusetts Emergency Management Agency (MEMA) 
2 State Police 


Examples of information to be exchanged include real-time information on incidents and delays, 
as well as planned events such as construction, road closures, or traffic-generating special 
events. While emergency management agencies are included in the list of participants, the 
system to be developed in this program area is only meant for the exchange of information for 
traffic and transit management purposes. Emergency management coordination is addressed 
by an extension of this system, as described in Section 2.9.1. 


This system will provide multiple ways for each agency to interface with the system. For 
agencies with central control center software, the system will support an automated interface 
with the agency, allowing event information to be sent directly to the system from the control 
center's central software. For agencies that have yet to implement central operations software, 
the event reporting system can also be used as a stand-alone system, with information entered 
by an operator through a web-based interface. 
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In addition to being used for information sharing among the participating agencies, the system 
will also serve as tool for information dissemination by allowing other users to view information 
entered into the system. These other users can include emergency management agencies, 
private information service providers, or even the public. The system can also serve as a 
source of data for the planned 511 Travel Information System, as described in Section 2.7.1. 


2.1.2 INFORMATION SHARING (VIDEO) 


This program area covers the sharing of video data between the various operations centers in the 
region. This addresses the center-to-center interfaces for video data that are shown in the 
architecture between roadway control centers. The functional areas covered by this program area 
are Traffic Management, Maintenance and Construction Management, Public Transportation, and 
Traveler Information. 


The interfaces covered by this program area can be implemented through an expansion to the 
Massachusetts Interagency Video Information System (MIVIS). The following initiative addresses 
this program area. 


Expansion of MIVIS 


MassHighway, BTD, MBTA, SmartRoutes, and the State Police have already established video 
sharing in the Boston area through the Massachusetts Interagency Video Information System 
(MIVIS). This initiative expands this system to allow sharing of real-time video feeds among a 
larger group of agencies. The primary participating agencies are those with video capabilities, 
including: 


» BTID 

« Local Cities/Towns (as applicable) 

=" MassHighway 

= MassPike / CA/T 

= Massport 

= Private Information Service Providers 
= State Police 


Other agencies, however, such as transit and other emergency management agencies, can also 
be included as recipients of the video data. This will support coordination among operations 
centers within the region, allowing one center to view the CCTV images from other participating 
agencies. The system will also provide travel information functions, allowing video to be 
distributed to private information service providers or publicly available websites, such as the 
planned 511 Travel Information System website, as described in Section 2.7.1. The system to be 
developed through this initiative is only meant for the exchange of video for traffic and transit 
management purposes. Emergency management coordination is addressed by an extension of 
this system, as described in Section 2.9.1. 


2.1.3 INTERAGENCY COMMUNICATIONS NETWORK 


This program area addresses the communications requirements of the center-to-center and center- 
to-field interfaces that are shown in the architecture. The functional areas covered by this program 
area are Traffic Management, Maintenance and Construction Management, Public Transportation, 
Traveler Information, and Archived Data Management. The following initiative addresses this 
program area. 
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Interagency Communications Network 


This initiative establishes a communications network linking the region’s roadway and transit 
agencies. The primary participating agencies are the following: 


«= BTID 

= Local Cities/Towns 
=" MassHighway 

= MassPike / CA/T 

= Massport 

= MDC 

= MBTA 


These agencies have developed or are developing communications networks to support their 
operational needs, but many of these networks do not provide the full coverage necessary for 
their operations. For example, many agencies fill the gaps in their communications networks with 
leased lines from private telecom providers, leading to high operational costs. 


This initiative takes advantage of the geographic overlap of many of these networks and 
addresses the communications requirements in two ways. First, opportunities for sharing 
existing communications infrastructure will be identified, leading to agreements for unused 
bandwidth on an agency’s network to be used by other agencies with need. This will allow better 
use of the existing network and eliminate unnecessary duplication of infrastructure. Second, 
existing gaps in the overall communications network will be identified, and these gaps will be 
filled though joint implementation projects. This will allow agencies to pool resources to build 
infrastructure that benefits each of the partners. 


The network to be developed in this program area this is meant for traffic and transit management 
purposes. Communications for emergency management is addressed in a separate initiative, as 
described in Section 2.9.1. 


2.2 Traffic Management: Roadway Management 


2.2.1 ROADWAY MONITORING 


This program area covers improvements to the traffic monitoring capabilities of the region’s 
agencies with traffic management functions. This addresses planned elements in the architecture 
relating to field surveillance, additional deployments of field equipment and control centers, and the 
interfaces of field equipment with the appropriate control center. 


This program area addresses the need for traffic data through two means: deployment of devices 
for monitoring traffic conditions on roadways, and obtaining traffic data through probe surveillance. 
The following initiatives fall under this program area: 


Traffic Monitoring Deployment (Local Cities/Towns, including Brockton) 


This initiative covers the further deployment of devices for monitoring traffic conditions on city 
and town roads. This will include placement of vehicle detectors and roadside CCTV cameras, 
as well as devices for monitoring roadway conditions such as weather sensors. This field 
equipment will be connected to local control centers, where it will provide data to control center 
operators. The initiative will cover the installation of these devices, establishment of control 
centers in municipalities where they are not currently present, and implementation of a 
communications link with the appropriate control center. 
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Traffic Monitoring Deployment (BTD) 


This initiative covers the further deployment of devices for monitoring traffic conditions on 
roadways operated by the Boston Transportation Department. This will include installation of 
vehicle detectors and CCTV cameras. This field equipment will be monitored at the BTD Traffic 
Management Center (TMC). The initiative will cover the installation of these devices along with 
the communications link to the TMC. 


Traffic Monitoring Deployment (MassHighway) 


This initiative covers the further deployment of devices for monitoring traffic conditions on 
roadways operated by MassHighway. This will include placement of vehicle detectors and 
roadside CCTV cameras. This field equipment will be connected to the MassHighway Traffic 
Operations Center (TOC), where it will be integrated into the TOC central software. The initiative 
will cover the installation of these devices along with the communications link to the TOC. 


Traffic Monitoring Deployment (Private Information Service Providers) 


This initiative covers private-sector deployment of field equipment for traffic monitoring. This 
equipment, including vehicle detectors and roadside CCTV cameras, will be linked to centers 
operated by private travel information service providers. The initiative will cover the installation of 
this equipment, communications links with the private operations center, and communications 
links from the private operations center to relevant public-sector operations centers. 


Highway Probe Surveillance (MassHighway, MassPike) 


This initiative makes use of existing and planned vehicle identification systems to produce travel 
time data for operations and planning purposes. The prime implementing agencies will be those 
managing highway operations, namely MassHighway and the Turnpike Authority. This initiative 
will make use of probe information from systems that provide vehicle identification, including 
Electronic Toll Collection (ETC) systems and Automatic Vehicle Location (AVL) systems. Either 
through ETC roadside readers or through AVL data provided by fleet operators, the agencies will 
obtain travel time information for roadways under their jurisdiction. 


2.2.2 ROADWAY CONTROL 


This program area covers improvements to traffic control capabilities for agencies with traffic 
management functions. This addresses planned elements in the architecture relating to information 
dissemination, as well as the interfaces of this equipment with the appropriate control center. The 
program area includes installation and expansion of centralized signal control systems as well as 
further deployment of field equipment. 


Expansion of City of Boston Centralized Signal Control (BTD) 


This initiative builds on the existing interface between the BTD Traffic Management Center and 
BTD Traffic Signals by expanding the scope of the centralized signal system. This initiative 
addresses a need for system expansion identified by BTD in the Needs Analysis. 


BTD operates approximately 400 signalized intersections under central control from its Traffic 
Management Center (TMC). In addition to city signals, certain signals owned by MDC, 
MassPike, and Massport are also operated from the TMC. This initiative increases the number 
of intersections tied into the central system, thereby expanding the coverage of the control 
center and allowing greater traffic control within the city. In addition to upgrades and further 
deployment of field equipment, this initiative also covers additional communication infrastructure 
to support the expanded system. 
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Centralized Signal Control (Local Cities/Towns, including Brockton) 


This initiative covers the integration of existing and new traffic signals into a centralized signal 
control system for a city or town. This would allow coordination of signals and adjustments to 
signal timings to be made in real-time from a centralized location. In addition to upgrades and 
further deployment of field equipment, this initiative also covers additional communication 
infrastructure to support the signal system. 


Expansion of Centralized Signal Control (MassHighway) 


This initiative builds on the existing interface between MassHighway Districts and MassHighway 
traffic signals by expanding the scope of existing closed-loop signal systems. This initiative 
increases the number of intersections tied into the systems at district offices, thereby expanding 
coverage and facilitating signal coordination within the region. In addition to upgrades and 
further deployment of field equipment, this initiative also covers additional communication 
infrastructure to support the expanded system. 


Variable Message Sign Deployment (BTD) 


This initiative comprises the deployment of Variable Message Signs (VMSs) on roadways 
operated by BTD. These VMSs will be controlled from the TMC, allowing real-time information to 
be disseminated to drivers on city streets. This information can include traffic conditions, routing 
information, and parking space availability. These signs will require a communications interface 
with the TMC. 


Variable Message Sign Deployment (Local Cities/Towns, including Brockton) 


This initiative comprises the deployment of Variable Message Signs on roadways operated by 
local cities and towns. These VMSs will be controlled from local control centers, allowing real- 
time information to be disseminated to drivers on city and town roads. This information can 
include traffic conditions, routing information, and parking space availability. These signs will 
require a communications interface with local control centers. 


Expansion of Variable Message Sign Deployment (MassHighway, MassPike) 


This initiative comprises the deployment of additional Variable Message Signs on roadways 
operated by MassHighway and the Turnpike Authority. Like those already deployed in the 
region, these VMSs will be controlled from the operating agency’s control center. In addition to 
upgrades and further deployment of field equipment, this initiative also covers additional 
communication infrastructure to support the system expansion. 


2.2.3 ROADWAY MANAGEMENT COORDINATION 


This program area covers improvements to coordination among agencies with traffic management 
functions. This addresses the center-to-center interfaces shown in the architecture among the 
various centers operated by traffic management agencies and private information service providers. 


In addition to the initiatives described in this section, there are a number of multi-function program 
areas that address Roadway Management Coordination, including the video integration and event 
reporting systems. These are described in Section 2.1. 


Remote MassHighway TOC Workstation 


This initiative consists of the installation of a back-up workstation for the Traffic Operations 
Center (TOC) at the Massachusetts Emergency Management Agency (MEMA) in Framingham. 
This workstation will allow viewing of event and response information at MEMA under normal 


Page 10 


IMPLEMENTATION PLAN REGIONAL ITS ARCHITECTURE FOR METROPOLITAN BOSTON 


operating conditions, and will allow remote operation of MassHighway field equipment under 
emergency operating conditions. This initiative will include the workstation hardware and 
software, as well as the necessary communications between the remote workstation and the 
TOC. 


Interface between MassHighway TOC and MassPike CA/T OCC (MassHighway and MassPike) 


This initiative provides a direct data interface between the MassHighway Traffic Operations 
Center (TOC) and the MassPike CA/T Operations Control Center (OCC). The interface will 
support the exchange of traffic data such as speed, flow, and occupancy between the two 
control centers. This will allow an operator at one control center to view output from selected 
traffic detectors from the other control center. 


2.3 Traffic Management: Parking Management 


2.3.1 ETC INTEGRATION FOR PARKING 


This program area covers acceptance of Electronic Toll Collection transponders at parking facilities 
within the region. This addresses the interfaces in the architecture between the MassPike FAST 
LANE transponders and various parking facilities and parking management systems. 


Agencies with parking facilities include BTD, Local Cities and Towns, Massport, and the MBTA. 
Due to the means by which the transponders are read, the use of the regional electronic collection 
transponders is limited to parking lots and garages with controlled entry and exit points. This 
implementation allows parking fees to be deducted from the user’s account balance. In addition to 
acceptance of the transponders at parking facilities, the system will also support reconciliation of 
accounts between each parking facility operator and the MassPike, who operates the current 
electronic toll collection program. 


ETC Integration at Parking Facilities (BTD) 


This initiative introduces acceptance of the regional ETC transponders at parking facilities 
operated by BTD. In addition to acceptance of the transponders at parking facilities, the system 
will also support reconciliation of accounts between BTD and the MassPike. 


ETC Integration at Parking Facilities (Local Cities/Towns, including Brockton) 


This initiative introduces acceptance of the regional ETC transponders at parking facilities 
operated by local cities and towns. In addition to acceptance of the transponders at parking 
facilities, the system will support reconciliation of accounts between local parking facility 
operators and the MassPike. 


ETC Integration at Parking Facilities (MBTA) 


This initiative provides for acceptance of the regional ETC transponders at MBTA-operated 
parking facilities, extending the current pilot project at the Route 128 Station parking garage. In 
addition to acceptance of the transponders at parking facilities, the system will support 
reconciliation of accounts between the MBTA and the MassPike. 


Logan Parking Management System (Massport) 


This initiative establishes a Parking Management System for the parking facilities at Logan 
Airport. As part of this system, the regional ETC transponders will be accepted for payment at 
the parking facilities. The system also includes revenue and inventory control functions, as well 
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as ITS elements such as pre-selling of parking spaces, parking space wayfinding, a pay-on-foot 
system for parking and bus ticketing, and display of parking information on airport VMSs. 


ETC Integration at Parking Facilities (Massport) 


This initiative introduces acceptance of the regional ETC transponders at Massport-operated 
parking facilities. As ETC payment at Logan parking facilities in included in the Logan Parking 
Management System project, this will cover facilities such as Logan Express parking lots. This 
system will make use of the existing agreement between Massport and the Turnpike for 
reconciliation of ETC accounts for Tobin Bridge tolls. 


ETC Integration at Parking Facilities (Other Parking Operators) 


In addition to the parking facilities operated by the agencies discussed above, there are a large 
number of parking facilities operated by other organizations. These organizations include other 
public agencies (e.g. the Massachusetts Convention Center Authority) as well as private 
companies. This initiative introduces acceptance of the regional ETC transponders at parking 
facilities parking facilities operated by these other organizations. In addition to acceptance of the 
transponders at parking facilities, the system will support reconciliation of accounts between 
parking facility operators and the MassPike. 


2.3.2 REGIONAL FARE CARD INTEGRATION FOR PARKING 


This program area covers acceptance of the planned Regional Fare Card, discussed in Section 
2.6.2, at parking facilities operated by agencies within the region. This addresses the interfaces in 
the architecture between the Regional Fare Card and the various parking facilities and parking 
management systems. 


Agencies with parking facilities include BTD, Local Cities and Towns, Massport, the MBTA, and the 
other Regional Transit Authorities. This program area covers metered parking as well as ticketed 
parking lots and garages, allowing parking fees to be deducted from the balance on a patron’s Fare 
Card. In addition to acceptance of the new media at meters and parking facilities, the systems will 
also support reconciliation of accounts between the parking operators and the Regional Fare Card 
agency. 


Automated Fare Collection for Parking Facilities (MBTA) 


This initiative extends the MBTA’s planned Automatic Fare Collection (AFC) system, described 
in Section 2.6.1, to MBTA parking facilities, allowing payment by fare card for parking fees. This 
will include fare card readers at parking facility exits, potentially additional fare vending machines 
at parking facilities, and upgrading the communications infrastructure to support the new data 
requirements. 


Regional Fare Card Integration at Parking Facilities (BTD) 


This initiative introduces acceptance of the planned Regional Fare Card at parking facilities 
operated by BTD. This includes both on-street metered parking as well as off-street municipal 
lots. In addition to acceptance of the new media at BTD parking meters, the system will also 
support reconciliation of accounts between BTD and the Regional Fare Card agency. 


Regional Fare Card Integration at Parking Facilities (Local Cities/Towns, including Brockton) 


This initiative introduces acceptance of the planned Regional Fare Card at parking facilities 
operated by local cities and towns. This will include metered parking as well as ticketed parking 
lots and garages. In addition to acceptance of the new media at meters and parking facilities, the 
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system will support reconciliation of accounts between the local parking operators and the 
Regional Fare Card agency. 


Regional Fare Card Integration at Parking Facilities (Massport) 


This initiative will introduce acceptance of the planned Regional Fare Card at Massport-operated 
parking facilities. This will include Logan parking facilities (through an extension to the Logan 
Parking Management System) as well as other facilities, such as Logan Express lots. In addition 
to acceptance of the new media, the system will support reconciliation of accounts between 
Massport and the Regional Fare Card agency. 


Regional Fare Card Integration at Parking Facilities (BAT, CATA, GATRA, LRTA, MVRTA) 


This initiative introduces acceptance of the planned Regional Fare Card at parking facilities 
operated by Regional Transit Authorities within the study area. In addition to acceptance of the 
new media parking facilities, the system will support reconciliation of accounts between each 
RTA and the Regional Fare Card agency. 


Regional Fare Card Integration at Parking Facilities (Other Parking Operators) 


This initiative introduces acceptance of the planned Regional Fare Card at parking facilities 
operated by other parking facility operators. In addition to acceptance of the new media at 
parking facilities, the system will support reconciliation of accounts between the parking 
operators and the Regional Fare Card agency. 


2.4 Maintenance and Construction Management 


2.4.1 ENVIRONMENTAL SENSORS 


This program area covers the deployment of environmental sensors on roadways in the region. It 
addresses the planned environmental sensor elements in the architecture, including those for BTD, 
Massport, and local cities and towns, as well as expansion of existing deployments. 


These devices include weather stations reporting measures such as air temperature and 
precipitation, as well as sensors reporting on the condition of the roadway surface. Through a 
communications link with a central control center, the sensors will provide their information on a 
computer interface for control center operators. 


Environmental Sensors (BTD) 


This initiative comprises the deployment of environmental sensors on roadways operated by 
BTD, as well as an interface with the BTD Traffic Management Center (TMC). 


Environmental Sensors (Local Cities/Towns, including Brockton) 


This initiative comprises the deployment of environmental sensors on roadways operated by 
local cities and towns, as well as an interface with local control centers. 


Environmental Sensors (Massport) 


This initiative comprises the deployment of environmental sensors on roadways operated by 
Massport, as well as interfaces with the relevant control centers (i.e. the Landside Operations 
Control Center, the Facilities Maintenance Unit, and/or the Aviation Operations Unit). 
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2.4.2 CAD/AVL FOR MAINTENANCE MANAGEMENT 


This program area covers the provision of Computer-Aided Dispatching/Automatic Vehicle Location 
(CAD/AVL) systems for managing maintenance vehicles. This addresses the planned interfaces in 
the architecture between control centers and maintenance vehicles, such as those of BTD, 
MassHighway, MassPike, and Massport. 


The systems to be implemented under this program area allow a control center to track its vehicles 
in real-time and to dispatch those vehicles in the most efficient manner. This program requires 
equipment in each vehicle to be tracked, as well as a central system at the dispatch center to 
receive and manage the tracking information. 


CAD/AVL for Maintenance Vehicles (Local Cities/Towns, including Brockton) 


This initiative provides CAD/AVL systems for managing city and town maintenance vehicles. 
This initiative will require equipment in each vehicle to be tracked, as well as a central system at 
the local dispatch center to receive and manage the tracking information. 


CAD/AVL for Maintenance Vehicles (MassHighway) 


This initiative provides a CAD/AVL system for managing MassHighway maintenance vehicles. 
Similar to the system in place for tracking the CaresVan roadway service patrol vehicles and 
snowplow contractors, this system will require equipment in each vehicle to be tracked, as well 
as central systems at the MassHighway District TOC and statewide TOC to receive and manage 
the tracking information. 


CAD/AVL for Maintenance Vehicles (MassPike) 


This initiative provides a CAD/AVL system for managing MassPike maintenance vehicles. This 
system will require equipment in each vehicle to be tracked, as well as a central system at the 
operations depots to receive and manage the tracking information. 


2.5 Public Transportation: Transit Management 


2.5.1 CAD/AVL FOR TRANSIT 


This program area covers the provision of Computer-Aided Dispatching/Automatic Vehicle Location 
(CAD/AVL) systems for managing transit vehicles. This addresses the planned interfaces in the 
architecture between transit control centers and transit vehicles for agencies such as the MBTA and 
the other Regional Transit Authorities, Local City/Town services, and other transit providers such as 
TMAs and local human service agencies. 


The systems to be implemented under this program area allow a dispatch center to track its 
vehicles in real-time and to manage its fleet more efficiently. This will be applicable to both fixed- 
route and paratransit operations centers. For fixed-route services, real-time tracking allows more 
efficient fleet management and allows the provision of real-time service status to passengers both 
pre-trip and en-route. For paratransit services, it allows more efficient dispatching and faster 
response time. 


This information is also used to provide real-time service status to passengers both pre-trip and en- 
route. The systems will require equipment in each vehicle to be tracked, as well as a central system 
at the dispatch center to receive and manage the tracking information. For the traveler information 
component, this system will also include a means for disseminating this information, such as 
electronic signs at shuttle stops or a websites with real-time information. 
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CAD/AVL for Transit Vehicles (Local Cities/Towns) 


This initiative provides a CAD/AVL system for managing local city and town transit vehicles. This 
initiative will require equipment in each vehicle to be tracked, a central system at the local 
dispatch center to receive and manage the tracking information, and a means for disseminating 
this information to the public. 


CAD/AVL for Transit Vehicles (MBTA) 


This initiative establishes a CAD/AVL system for managing MBTA buses. Similar to the system 
in place for the Silver Line buses, this system will allow the Bus Operations Center to track 
vehicles in real-time and to manage the fleet more efficiently. This information will also be used 
to provide real-time service status to passengers both pre-trip and en-route. This initiative will 
require equipment in each vehicle to be tracked, a central system at the Operations Center to 
receive and manage the tracking information (perhaps building on the existing system for the 
Silver Line), and a means for disseminating this information to the public. 


CAD/AVL for Transit Vehicles (BAT, CATA, GATRA, LRTA, MVRTA) 


This initiative provides a CAD/AVL system for managing transit vehicles operated by Regional 
Transit Authorities within the study area, allowing an RTA dispatch center to track its vehicles in 
real-time. This initiative will require equipment in each vehicle to be tracked, a central system at 
each RTA dispatch center to receive and manage the tracking information, and a means for 
disseminating this information to the public. 


CAD/AVL for Transit Vehicles (Other Transit Providers) 


In addition to the MBTA and the other RTAs, there are a number of other providers of transit 
service in the region. These include Transportation Management Associations (TMAs), local 
human service transit providers, as well as private paratransit operators under contract with the 
MBTA. This initiative establishes a CAD/AVL system for managing transit vehicles operated by 
these other transit providers, allowing a transit dispatch center to track its vehicles in real-time. 
This initiative will require equipment in each vehicle to be tracked, a central system at each 
dispatch center to receive and manage the tracking information, and a means for disseminating 
this information to the public. 


2.5.2 TRAFFIC SIGNAL PRIORITY 


This program area covers signal priority for buses operated by transit agencies within the study 
area. This addresses the planned interfaces between transit vehicles and traffic signal systems 
shown in the architecture. 


The systems to be implemented under this program area require coordination between the relevant 
agency and the cities or towns in which signal priority will be requested for buses. Requests for 
traffic signal priority will be made to the traffic signal system controlled by the local city/town. This 
will occur either locally at the signal controller or through a request to the central system, if the 
signal is part of such a system. Depending on the type of system used, the system may include 
elements on the buses to identify them to the signal system, elements on the controller hardware in 
the field, elements in the central signal system, and the network infrastructure to support 
communications between these system elements. 


Traffic Signal Priority (MBTA) 


This initiative extends the signal priority system currently in place on the Silver Line to other bus 
routes in the MBTA system. This will require coordination with BTD and any other cities or towns 
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in which signal priority will be requested for MBTA buses. Requests for traffic signal priority will 
be made to the traffic signal system controlled by BTD or the local city/town. 


Traffic Signal Priority (BAT, CATA, GATRA, LRTA, MVRTA) 


This initiative introduces signal priority on buses operated by Regional Transit Authorities within 
the study area. This will require coordination the relevant RTA and the cities or towns in which 
signal priority will be requested for buses. Requests for traffic signal priority will be made to the 
traffic signal system controlled by the local city/town. 


2.6 Public Transportation: Electronic Fare Payment 


2.6.1 AUTOMATED FARE COLLECTION FOR THE MBTA 


This program area covers the replacement of the MBTA’s existing fare collection system with a fare 
card system. This addresses the planned element of the Regional Fare Card in the architecture, as 
well as its interfaces with MBTA transit services. The system will cover fare collection on all 
subway, trolley, and bus services, with planned expansion to MBTA commuter rail services. 


Automated Fare Collection for Subway/Bus (MBTA) 


This initiative, currently being implemented, replaces the existing fare collection system with a 
cashless system based on fare cards. The Automated Fare Collection (AFC) system will consist 
of upgrades to turnstiles and fareboxes to accept the new fare media, vending machines for the 
new fare cards, a centralized fare collection and revenue management system, and supporting 
communications infrastructure upgrades. The system will cover fare collection on all subway, 
trolley, and bus services. 


Automated Fare Collection for Commuter Rail (MBTA) 


This initiative extends the AFC system to MBTA commuter rail services, allowing payment by 
fare card for commuter rail trips. This will include fare vending machines at commuter rail 
stations, fare card readers at stations or aboard trains, and upgrading the communications 
infrastructure to support the new data requirements. 


2.6.2 REGIONAL FARE CARD 


This program area covers acceptance of the planned Regional Fare Card (envisioned in the 
architecture to be interoperable with the MBTA’s automated fare collection system) on non-MBTA 
transit services. This program area addresses the planned interfaces in the architecture between 
the Regional Fare Card and services operated by the Regional Transit Authorities and other transit 
providers. 


The systems to be implemented under this program area will allow fares on these services to be 
deducted from the balance carried on the Fare Card. In addition to acceptance of the new media 
aboard the vehicles, the system will also support reconciliation of accounts between the transit 
operator and the Regional Fare Card agency. 


Regional Fare Card Integration for Transit Vehicles (Local Cities/Towns) 


This initiative introduces acceptance of the planned Regional Fare Card on local shuttle services 
operated by local cities and towns. In addition to acceptance of the new media aboard the 
shuttles, the system will support reconciliation of accounts between the shuttle service operator 
and the Regional Fare Card agency. 
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Regional Fare Card Integration for Transit Vehicles (BAT, CATA, GATRA, LRTA, MVRTA) 


This initiative introduces acceptance of the planned Regional Fare Card on transit services 
operated by Regional Transit Authorities within the study area. In addition to acceptance of the 
new media aboard transit vehicles, the system will support reconciliation of accounts between 
the RTA and the Regional Fare Card agency. 


Regional Fare Card Integration for Transit Vehicles (Other Transit Providers) 


This initiative introduces acceptance of the planned Regional Fare Card on transit services 
operated by other transit providers in the region. In addition to acceptance of the new media 
aboard the buses, the system will support reconciliation of accounts between the appropriate 
transit provider and the Regional Fare Card agency. 


2.6.3 REGIONAL FARE CARD INTEGRATION FOR ETC 


This program area covers the integration of the Regional Fare Card with the regional electronic toll 
collection (ETC) transponders. This addresses the planned interface shown in the architecture 
between the Regional Fare Card and the MassPike FAST LANE transponders. The following 
initiative addresses this program area. 


Regional Fare Card Integration with ETC Transponders (Regional Fare Card Agency and MassPike) 


This initiative covers the integration of the Regional Fare Card with the regional ETC 
transponders. This initiative will extend the planned Regional Fare Card for use in highway toll 
transactions, allowing transfer of funds from the fare card to the toll transponder. In addition to 
acceptance of the fare card media by the toll transponder, the system will also support 
reconciliation of accounts between the MassPike (the operator of the FAST LANE system) and 
the Regional Fare Card agency. 


2.7 Traveler Information 


2.7.1 REGIONAL TRAVEL INFORMATION 


This program area covers the deployment of a regional travel information system, including a 
telephone-based system as well as other systems (e.g., websites, kiosks) covering the region’s 
roadways and transit services. This program covers the regional implementation of the planned 
statewide 511 Travel Information System. This addresses the planned Travel Information 
Interactive Telephone System in the architecture, as well as its interfaces with MassHighway and 
Private Information Service Provider Operations Centers. The following initiative addresses this 
program area. 


511 Travel Information System 


This initiative consists of the deployment of a public travel information system, covering the 
roadways and transit services in the region. The participating agencies are the following: 


=" Roadway Agencies: 
2 BTD 
a City of Brockton 
2 Local Cities/Towns 
o MassHighway 
a MassPike / CA/T 
co _Massport 
2 MDC 
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«Transit Agencies: 


a =BAT 

a CATA 

a GATRA 
a LRTA 

a MBTA 

a MVRTA 


2 Local Cities/Towns 
o Other Transit Providers 


Although the lead agency for implementation will be MassHighway, all roadway and transit 
agencies in the region can provide information for dissemination through the system to be 
implemented under this program area. Examples of information to be provided include real-time 
information on incidents and delays, as well as planned events such as construction, road 
closures, or traffic-generating special events. 


The system will provide travel information consolidated from the various roadway and transit 
agencies in the region. A travel information website will supplement the information provided 
over the phone-based system. The proposed event reporting system, described in Section 2.1.1, 
can serve as a source of data for this system, allowing event information to be collected from the 
various participating agencies for dissemination to the public via the telephone system and its 
associated website. 


2.7.2 AGENCY-SPECIFIC TRAVEL INFORMATION 


This program area covers the development or expansion of travel information systems specific to 
particular roadway and transit agencies. This addresses planned components in the architecture 
relating to travel information dissemination, such as information kiosks and websites, as well as 
their interfaces with the appropriate travel information system. 


The systems to be implemented under this program area consist of central information systems that 
serve as an agency’s travel information repository, as well as the elements allowing dissemination 
of information to the public. 


Travel Information Website (BTD) 


This initiative establishes a travel information website for the City of Boston, covering the 
roadways operated by BTD. The website will provide information from the TMC such as traffic 
advisories and CCTV images. The server for this website will obtain information from the central 
systems at the TMC for dissemination to the public via the World-Wide Web. 


Travel Information Kiosks (MassPike) 


This initiative comprises the deployment of Travel Information Kiosks at service areas along the 
MassPike. The kiosks will provide travel information such as traffic conditions and weather 
advisories, as well as tourism information. These kiosks will require connections to central 
servers at the Turnpike Authority where the information will reside. 


2.8 Commercial Vehicle Operations 


2.8.1 AUTOMATED OVERSIZE/OVERWEIGHT CREDENTIALING 


This program area covers the provision of electronic systems for managing oversize/overweight 
vehicle permits. This addresses the elements planned in the architecture for this purpose, namely a 
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central system for managing these permits electronically at Oversize/Overweight Permit Offices, as 
well as an interface with Private Motor Carriers. The following initiative addresses this program 
area. 


Automated Oversize/Overweight Credentialing System 


This initiative establishes a computer-based system for managing oversize/overweight (OS/OW) 
vehicle permits. This includes a central system for managing these permits electronically at the 
Oversize/Overweight Permit Office at BTD, as well as an interface with Private Motor Carriers. 
This interface will allow electronic submission of credentials and permit applications, as well as 
electronic distribution of permits and credential status confirmations. 


2.9 Emergency Management 


2.9.1 EMERGENCY MANAGEMENT COORDINATION 


This program area covers the extension of the Interagency Communications Network and the Event 
Reporting and Video Integration Systems to support emergency management functions for the 
transportation systems in the region. This covers the planned center-to-center interfaces among 
emergency operations centers, as well as interfaces between emergency management and 
traffic/transit management centers. The following initiative addresses this program area. 


Emergency Management Network 


This initiative extends the functionality of the interagency systems proposed in the architecture, 
namely the Interagency Communications Network and the Event Reporting and Video 
Integration Systems, to support emergency management functions. The participating agencies 
are those with roadway, transit, or emergency management functions, including the following: 


=" Roadway Agencies: 
2 BTD 
2 City of Brockton 
2 Local Cities/Towns 
o MassHighway 
ao MassPike / CA/T 


a Massport 
o MDC 
= Transit Agencies: 

o ~=©6BAT 
2 CATA 
2 GATRA 
o LRTA 
o MBTA 
o MVRTA 


2 ~—Local Cities/Towns 
© Other Transit Providers 


=» Emergency Management Agencies: 
2 BEMA 
2 Local City/Town Public Safety 
2 MBTA Police 
2 MEMA 
2 State Police 
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In emergency management, coordination among agencies may often require the transmission of 
sensitive or privileged information. This includes information that must remain restricted due to 
security concerns and that must be managed more securely. This initiative addresses this need 
by adding a secure layer to these systems, allowing sensitive information to be accessible only 
to users with appropriate privileges. Once a user’s identification is established (e.g. through 
password or other means of verification), each user will be able to view information appropriate 
for his/her access level. 


The initiative also extends the event reporting system, described in Section 2.1.1, to support new 
categories and protocols for information exchange. This includes incident information essential 
for emergency response (e.g. nature of event or threat, severity, etc.) as well as response 
information (e.g. units dispatched, response plans, route diversions, etc.). The initiative also 
includes the development of tools for evacuation planning and management, allowing a 
coordinated response in case of local or regional evacuations. 


2.9.2 CAD/AVL FOR EMERGENCY MANAGEMENT 


This program area provides Computer-Aided Dispatching/Automatic Vehicle Location systems for 
managing emergency vehicles. This addresses the planned interfaces in the architecture between 
emergency dispatch centers and emergency vehicles. The following initiative addresses this 
program area. 


CAD/AVL for Emergency Vehicles (Local Cities/Towns) 


This initiative provides a CAD/AVL system for managing emergency vehicles. This system will 
allow a local or regional emergency dispatch center to track its vehicles in real-time and to 
dispatch those vehicles in the most efficient manner. This initiative will require equipment in each 
vehicle to be tracked, as well as a central system at the dispatch center to receive and manage 
the tracking information. 


2.9.3 TRANSIT SAFETY 


This program area covers the deployment of emergency call boxes at transit facilities. This 
addresses the planned emergency call box elements in the architecture, as well as the interfaces 
with the emergency call centers. The following initiative addresses this program area. 


Emergency Call Boxes (CATA, GATRA, LRTA, MVRTA) 


This initiative comprises the deployment of emergency call boxes at Regional Transit Authority 
facilities. Locations for deployment will include bus stops, terminals, and parking facilities. These 
call boxes will allow a voice connection to security personnel either at RTA control centers or at 
relevant police dispatch centers. They will also support silent alarms, alerting security personnel 
to a problem without the need for voice communications. This initiative will require a 
communications interface between the call boxes and the dispatch center. 


2.10 Archived Data Management 


2.10. 1PLANNING DATA ARCHIVE COORDINATION 


This program area covers the development of interfaces among the planning data archives held by 
transportation agencies in the region. This addresses the planned interfaces between the Office of 
Transportation Planning (OTP) archive and the other databases in the region. The following 
initiative addresses this program area. 
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Planning Data Archive 


This initiative consists of the development of a system for coordinating the planning data 
archives for the transportation agencies in the region. The system will provide access to the 
planning data collected by roadway and transit agencies, planning agencies such as the five 
RPAs and CTPS, and the Registry of Motor Vehicles. As envisioned by the architecture, OTP 
will serve as the regional archived data management system hub, holding information managed 
by OTP as well as providing a portal to the information held by other agencies. This initiative will 
require interfaces between OTP and each of the other participating agencies’ databases. This 
will provide OTP with access to data held by the other agencies, and will provide the other 
agencies with access to data held by OTP. Moreover, this will also provide participating 
agencies with access to each others’ data, allowing one RPA, for example, to access data held 
by an adjacent RPA through the system maintained by OTP. 
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3. IMPLEMENTATION STRATEGY 


When implemented, the initiatives identified in the previous section will provide the integrated 
transportation system envisioned by the Regional ITS Architecture. However, due to limitations in 
resources and time, it is not possible to implement of all of these initiatives immediately. Therefore, 
this section recommends a strategy for the implementation of these initiatives, taking into account 
existing agency initiatives and program areas, regional needs, and potential for successful 
implementation. 


Many initiatives in this plan, however, are identified for implementation by a single agency. For 
example, there are a number of initiatives that can be implemented independently by a local city or 
town, such as CAD/AVL for emergency vehicles, CAD/AVL for maintenance vehicles, or variable 
message signs. As these initiatives are independent of any other agency or organization, this 
implementation strategy does not address them. Prioritization of these initiatives will be the 
responsibility of the implementing agency, as only that agency will be able to determine how these 
initiatives fit into its overall capital and operational planning strategies. 


Therefore, this strategy only addresses initiatives that require the participation of multiple agencies 
or organizations. For the purposes of this plan, the multi-agency initiatives have been sorted into 
two categories: “near-term” and “future.” The determination of which group an initiative falls into is 
based on a number of factors. The primary source is the Needs Analysis, in which specific 
initiatives were identified by agencies as high priority and in which a number of critical needs and 
themes were identified. In addition, initiatives of clear relevance to specific needs identified in the 
needs analysis were also given priority. However, in addition to an initiative’s priority and 
relevance, dependencies between initiatives must also be considered. For example, an initiative 
that has others dependent on its completion should be elevated in priority to avoid delays to these 
other initiatives. 


The recommended “near-term” multi-agency initiatives are presented in Exhibit 3-1. These include 


ones that are currently under development, as well as ones that are not ongoing but are seen as 
critical for the region. 


Exhibit 3-1: Recommended Near-Term Multi-Agency Initiatives 





Functional Area_| Initiative 





= Event Reporting System 

= Expansion of MIVIS 

Multimodal » Interagency Communications Network 
= 511 Travel Information System 


Planning Data Archive 





= Remote MassHighway TOC Workstation (MassHighway and MEMA) 


Roadwa 
= Interface between MassHighway TOC and MassPike CA/T OCC 





Transit « Traffic Signal Priority for MBTA Vehicles 





= Logan Parking Management System 


Parkin 
2 = ETC Integration at MBTA Parking Facilities 
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Specific considerations for each of the initiatives are discussed below: 


"The Event Reporting System initiative has been identified as high priority as it addresses 
interagency coordination, a key need identified through the architecture development 
process. In addition, as the system serves as a centralized information repository, it will be 
a source of data for other initiatives, such as the planned 511 Travel Information System 
and the planned Emergency Management Network. Implementation of this initiative, either 
as an expansion of the existing pilot system or as an independent effort, is therefore key to 
moving ahead with these other initiatives. 


=" The Expansion of MIVIS addresses the need for interagency coordination by allowing the 
sharing of video images among agencies. The initiative also supports emergency 
management, which was identified as another regional need. This system can provide a 
source of data for the proposed 511 Travel Information website and the planned 
Emergency Management Network. Expansion of this system will support the development 
of these other important initiatives. 


=" The Interagency Communications Network is a high priority initiative because it supports 
the communications requirements of all other initiatives in the Implementation Plan, and is 
especially key for center-to-center coordination needs. It also has the potential to 
significantly reduce agency operational costs through the elimination of leased 
communication lines, which was a key concern that was identified in the needs analysis. 


" The 511 Travel Information System initiative is currently under development. This 
initiative also addresses the need for travel information, another need identified through the 
architecture development process. 


= The Planning Data Archive initiative was identified as high-priority because it addresses 
the need for coordination of ITS data for planning purposes. During the architecture 
development process, regional planning stakeholders indicated that data being collected for 
operational purposes would have significant value for planning purposes, but that this data 
was not currently being utilized. 


« The initiative to implement a Remote MassHighway TOC Workstation at the MEMA 
operations center is currently under development. This initiative addresses the need for 
center-to-center coordination. It also provides a backup system for emergency operations, 
addressing safety and security needs. 


= The initiative to develop an Interface between MassHighway TOC and MassPike CA/T 
OCC was specifically identified as high priority in the needs analysis. It also addresses the 
key need of center-to-center coordination. 


" Traffic Signal Priority for the MBTA is an ongoing initiative, currently focused on priority 
for the Silver Line in Boston. This initiative is planned to continue as part of the 
development of the Urban Ring. 


"The Logan Parking Management System initiative is currently under development. The 
multi-agency component of this initiative is the integration with MassPike ETC 
transponders. 


"The MBTA’s initiative for ETC Integration at Parking Facilities builds on the existing pilot 
project for acceptance of MassPike ETC transponders. 
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The remaining multi-agency initiatives are identified as future initiatives and are presented in Exhibit 
3-2. As discussed previously, the determination of the initiatives as “future” rather than “near-term” 
is based primarily on the needs analysis. Therefore, if the needs of the region change, the 
classification of the initiatives should be reconsidered. For example, if a regional transit agency 
identifies a crucial need for traffic signal priority at a particular intersection, this initiative could be 
implemented in the near-term, as it does not depend on the completion of any other initiatives. If 
other initiatives are related, however, these should be considered. For example, if an RTA wishes 
to move integration of the Regional Fare Card to the near-term, coordination with similar initiatives 
by other RTAs will be a factor. 


As Exhibit 3-2 shows, there are a number of initiatives that are shared by many agencies, such as 
the signal priority and Regional Fare Card integration initiatives. Although not required, coordinated 
implementation of initiatives across these agencies is recommended, since the agencies involved, 
as well as the public, would benefit from the coordinated approach and broad-based deployment. 


Exhibit 3-2: Future Multi-Agency Initiatives 





Functional Area Initiative (and Lead Agency) 





= Emergency Management Network 





Multimodal . 

« Regional Fare Card Integration with ETC Transponders 

= Traffic Signal Priority (BAT, CATA, GATRA, LRTA, MVRTA) 
Transit = Regional Fare Card Integration for Transit Vehicles 


(BAT, CATA, GATRA, LRTA, MVRTA, Cities/Towns, Other 
Transit Providers) 





= ETC Integration at Parking Facilities 
(BTD, Cities/Towns, Massport, Other Parking Operators) 


Parking » Regional Fare Card Integration at Parking Facilities 
(BTD, Cities/Towns, Massport, MBTA, Other Parking Operators, 
BAT, CATA, GATRA, LRTA, MVRTA) 
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4. ARCHITECTURE CONSISTENCY AND MAINTENANCE 


The Implementation Plan discussed in the preceding section outlines a strategy for implementation 
of the ITS components contained in the architecture. However, it is recognized that in order for ITS 
implementation to be successful, ITS must be integrated into the mainstream transportation 
planning process. This section addresses two separate but related issues. The first is ensuring 
that when projects are developed, any ITS elements are consistent with the architecture. The 
second is maintaining the architecture so that it remains relevant and useful to stakeholders in the 
region. Both of these are valuable exercises, and both are also the subject of the federal rules and 
policies governing metropolitan planning. 


As it did for the development of the architecture, the Office of Transportation Planning will take 
responsibility for the oversight of the architecture for Metropolitan Boston. This approach recognizes 
the complexity of coordinating planning across five MPO regions. To be successful, this approach 
will require ongoing information exchange and collaboration among the stakeholders in this region. 


This section outlines the approach by which OTP plans — in collaboration with stakeholders in the 
region — to address the federal consistency and maintenance requirements. This approach 
recognizes the importance of integrating ITS planning into the mainstream transportation planning 
process. Therefore, ensuring consistency between projects with ITS elements and the architecture 
is based on the MPO-oriented capital programming process, and maintaining the Regional ITS 
Architecture is designed to be responsive to updates of the long-term regional transportation plans 
and other planning activities. The following sections present the proposed approach. 


4.1 Architecture Consistency 


The United States Department of Transportation is responsible for ensuring that federal 
transportation dollars are used in a manner that is consistent with federal laws and regulations, 
including the Clean Air Act, the Americans with Disabilities Act, and others. As stated in the 2001 
FHWA Rule and FTA Policy: 


“The final design of all ITS projects funded with highways trust funds shall accommodate 
the interface requirements and information exchanges as specified in the regional ITS 
architecture. If the final design of the ITS project is inconsistent with the regional ITS 
architecture, then the regional ITS architecture shall be updated.”' 


As with the other federal requirements, this ITS consistency policy means that if agencies seeking 
federal funds want to avoid costly delays during the approval and funding process, they need to be 
sure that the consistency requirement has been met. The objective of the policy is to help an 
agency at the earliest stage possible to realize the opportunities for collaboration with other 
stakeholders, to take advantage of synergies with projects under development at other agencies, 
and to avoid conflicts or duplication of effort. 


The federal regulations also require that all ITS projects be based on a systems engineering 
analysis at a scale commensurate with the project scope, meaning that the more complex the 
project, the more complex the analysis. Such an analysis is typical of any transportation 
engineering project involving the application of advanced technology. While the architecture has 
relevance throughout the project development process, the discussion in this section focuses on the 
initial review for architecture consistency in the early stages of the process. 





' Federal Highway Administration “Intelligent Transportation System Architecture and Standards; Final Rule” and Federal Transit 
Administration “National ITS Architecture Policy on Transit Projects; Notice” in Federal Register volume 66 number 5, Monday, January 8, 


2001. 
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Since the passage of the Intermodal Surface Transportation Efficiency Act (ISTEA) in 1991, 
transportation planning has been driven by a set of rules governing metropolitan and statewide 
transportation planning. The path that leads from a project concept to federal approval and funding 
goes through two major phases: project initiation and federal approval. The former involves all of 
the work that leads up to submission of a project to a Metropolitan Planning Organization; the latter 
begins with the adoption by that MPO of a fiscally-constrained, prioritized set of projects known as a 
Transportation Improvement Program (TIP), and concludes with federal approval of the state TIP 
(STIP), which is an aggregation of TIPs from around the state, as shown in Exhibit 4-1. The process 
for addressing consistency with the Regional ITS Architecture is designed to fit into this existing 
transportation planning process. As such, this approach relies on existing collaborative 
relationships between each MPO and its local planning partners. 


Project Initiation Federal Approval 


Project 


Concepts 





Exhibit 4-1: Project Planning Process 


4.1.1 FEDERAL APPROVAL PHASE 


Because the rule/policy driving this process is focused on the final approval granted by FHWA and 
FTA, the description of the process begins with the federal approval phase. During the federal 
approval phase, each MPO submits its TIP to the state. In Massachusetts, the State Transportation 
Improvement Program (STIP) is an aggregation of the TIPs from around the state and the 
Executive Office of Transportation is responsible for submitting the STIP for approval by FHWA and 
FTA. The approach to addressing the consistency requirement that was developed by the Guidance 
Committee and Project Team was designed to fit into this process. As the discussion of the project 
initiation process explains, a project with ITS elements should not reach the TIP unless consistency 
has been addressed. As a result of addressing the issue before projects reach the TIP, each TIP 
that is submitted to EOT — and by extension the STIP — should be ready for federal approval with 
respect to the consistency issue. 


4.1.2 PROJECT INITIATION PHASE 


The project initiation phase begins with project concepts. By the end of this stage when the TIP is 
being developed, each MPO needs to be certain that the consistency requirement has been 
addressed for all projects that have ITS elements. Each MPO, therefore, will work with its planning 
partners during the project initiation phase, when concepts are being developed for eventual 
inclusion in the TIP, to ensure that the consistency issue is addressed. 


As planning practices vary by region, differences are expected among the MPOs in Massachusetts 
but in general it is expected that the focus will be on whichever agency or entity assumes 
responsibility for a project concept’s development. The role of “project proponent” is often assumed 
by a Regional Transit Authority or MassHighway District office, which often facilitate the 
development of a concept. Consultants and contractors, who often provide extensive technical 
assistance, could also occupy this niche on behalf of their client, as could the individual 
municipalities that often champion specific projects. Regardless of who acts as the project 
proponent, however, the MPO will want to know if a project that has ITS elements is consistent with 
the architecture. Based on input from MPO participants in each region, it is anticipated that this will 
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be handled through the project submission forms employed by each MPO. These forms, which 
document many project attributes, vary among the MPOs. By adding architecture consistency as an 
additional attribute, the MPOs can ensure that the consistency requirement is addressed within 
existing planning practices. 


In this context, it is necessary to differentiate roadway and transit projects, because the paths 
through which they reach the MPO are different in some respects. Transit projects are developed 
and eventually submitted by transit authorities, of which there are seven in the area covered by this 
architecture. Each transit authority develops a list of capital projects, which depend on funds over 
which the MPO has authority. For all kinds of projects but especially for major projects, the 
authorities tend to work closely with the Federal Transit Administration, and proposals are often 
scrutinized closely for various policy issues before they reach the TIP. In most cases, therefore, the 
authority acts as a project proponent. When projects are submitted for inclusion in the TIP, 
regardless of scope or funding type, the transit authority, as project proponent, will document 
whether or not the project has ITS elements and, if it does, that the transit authority affirms that they 
are consistent with the architecture. 


In contrast, aside from major highway improvements, roadway projects tend to begin with an 
advocate such as a city or town within the region proposing an idea to the appropriate 
MassHighway District office. In general, therefore, the Districts will serve as the project proponent 
for most roadway projects from the region that will eventually reach the TIP. When roadway projects 
are submitted for inclusion in the TIP, the District, as the project proponent, will document whether 
or not each project has ITS elements and, if it does, will affirm that they are consistent with the 
architecture. 


For roadway projects, there is another piece of the project initiation phase that happens to benefit 
the consistency requirement. A Project Initiation Form (PIF), required of all project concepts, is 
often drafted by the project advocate and completed by the District, which then submits each PIF to 
a statewide Project Review Committee. This creates an additional opportunity to ensure that the 
project proponent has examined the project for consistency with the architecture. 


This process is illustrated in Exhibit 4-2: 


PROJECT INITIATION PHASE FEDERAL APPROVAL PHASE 











Project Review 
Committee 

















Roadway 








Project Proponent 
(MassHighway District) 




















Metropolitan Executive 
Planning | Office of FHWA/ 
Organization “) Transportation FTA 
(TIP) (STIP) 





























; Project Proponent 
Transit (Transit Authority) 
































Exhibit 4-2: Project Initiation and Approval Process 
In addition to this initial review in the early stages of the project development process, consistency 


with the architecture must be revisited as a project develops further in order to ensure that it has not 
been affected by changes to the scope of the project. Moreover, as a project progresses into the 
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design stage, it must undergo a systems engineering analysis, as is typical of ITS projects and as is 
required by the federal Rule and Policy. 


A note about the term “consistency”: 


Because of the superficial similarity to air quality conformity, it is important to clarify the 
differences between the terms consistency and conformity. Whereas air quality goals are 
definitive and fixed, the Regional ITS Architecture is a dynamic product of the transportation 
planning process. The goal of air quality conformity is, in large part, to filter out detrimental 
projects; the intent of the ITS consistency policy is to ensure that when actual projects are 
developed and become candidates for federal funding, the technical and institutional aspects 
are consistent with the architecture. A project may prompt a modification to the architecture, as 
discussed in Section 4.2.2, or may be revised to be consistent with the architecture. As such, 
demonstrating consistency places a great emphasis on considering the relationship between a 
project and the architecture as early and as often as possible. 


4.2 Architecture Maintenance 


Comparable to a Regional Transportation Plan (RTP), the Regional ITS Architecture is a vision of 
the future transportation system, documented at one point in time. The architecture, like an RTP, 
reflects the current situation and documents planned changes or investments. However, in order to 
remain relevant, the architecture has to be maintained. As regional needs evolve, as planned 
elements are deployed, and as other changes occur, the architecture must be updated to reflect 
those developments. Maintenance of the architecture is also motivated by federal requirements that 
require consistency between all federally funded projects with ITS elements and the Regional ITS 
Architecture. 


This section describes how the architecture will be maintained so that it remains relevant to the 
transportation system and useful to planners and operators. The maintenance strategy relies on two 
elements. The first is a formal periodic update at the same frequency as the RTPs, which are 
currently on a three-year update cycle. However, since the RTPs will provide valuable input to the 
architecture, the architecture update process will be staggered to occur after the RTP update. The 
second is interim architecture modifications that may occur at any point in the update cycle, outside 
of the formal update process. This two-pronged approach will have the added benefit of sustaining 
an ongoing region-wide dialogue about ITS. 


The Office of Transportation Planning, which has led the initial development of the Regional ITS 
Architecture, will be responsible for the maintenance of the architecture. However, other 
stakeholders will be involved, as they have been throughout the development process. The 
maintenance strategy describes who will be involved and what responsibilities transportation 
stakeholders in the region should assume. 


4.2.1 PERIODIC ARCHITECTURE UPDATES 


Under this strategy, the Regional ITS Architecture will be formally revisited on the same cycle as 
the Regional Transportation Plan updates (currently every three years), with timing that allows the 
architecture update to take a revised RTP into consideration. In this way, it is expected that the 
revised architecture can incorporate new ideas and/or projects that are included in an updated RTP. 


The Office of Transportation Planning will initiate the Regional ITS Architecture update process with 
a request for information from stakeholders in the region regarding new ITS-related projects, 
initiatives, or needs. OTP will also gather information from the stakeholders in order to evaluate the 
status of the architecture’s implementation, identifying, for example, ITS elements or interfaces that 
have evolved from “planned” to “existing” or that are no longer relevant and should be removed. 
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Based on the information gathered through this process, OTP will generate a draft list of 
architecture modifications and distribute it to the stakeholders for review. OTP can then call a 
stakeholder meeting for the region to review the draft list. This meeting can also provide an 
opportunity to discuss emerging ITS issues. After the stakeholder review of the draft list, OTP will 
make any modifications necessary and release the updated architecture. 


4.2.2 INTERIM ARCHITECTURE MODIFICATIONS 


Just as project developments necessitate TIP amendments, it is anticipated that some modifications 
to the architecture will be needed during the interval between the periodic updates. Therefore, on 
the basis of project developments or other circumstances that require modifications, the project 
proponent will be responsible for drafting an architecture modification proposal and submitting it to 
OTP. The proposal will then be circulated to affected stakeholders for their review. It is expected 
that most architecture modifications, whether periodic or interim, will involve adding new ideas, 
dimensions, or stakeholders to existing market packages, interfaces, or functions. 


4.2.3 SUMMARY 


This maintenance strategy is meant to accomplish several objectives. First, it ensures that the 
architecture will remain current and will reflect the most recent Regional Transportation Plans. 
Second, it allows the architecture to be responsive to changes between updates. And third, it helps 
facilitate an ongoing dialogue about ITS and the implementation of the architecture. Through the 
interim modifications and the periodic updates, this strategy should help to integrate ITS into the 
mainstream transportation planning process. 
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5. CONCLUSION 


This Implementation Plan outlines a strategy for achieving the integrated transportation system 
envisioned by the Metropolitan Boston Regional ITS Architecture. The strategy consists of a 
number of program areas for ITS investment, a series of initiatives within each program area, 
recommendations for prioritization of these projects, and a plan for maintaining the architecture. It 
is important to note that the strategy recommended is a direct outcome of the architecture 
development process, which originates with an analysis of the needs of the region and its 
stakeholders, and which relies on stakeholder input throughout the entire process. 


It is also important to note that the plan presented is not the only means by which the architecture 
can be implemented. While some of the projects in the plan are currently being designed and 
implemented, others are recommendations for addressing the needs and planned components 
identified in the architecture development process. The architecture is meant to be a living 
document that is updated on a recurring basis to reflect the changing needs and priorities of the 
region. Therefore, as the region’s needs and the architecture change, the priorities of the various 
initiatives will change as well. For this reason, continued involvement of all the stakeholders in the 
region is essential in maintaining the Regional ITS Architecture and its recommendations and 
priorities. 
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